home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 639 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.3 KB
  1. Path: news.iadfw.net!usenet
  2. From: Larry Weiss <lfw@iadfw.net>
  3. Newsgroups: comp.std.c
  4. Subject: Re: externsions and Standard C
  5. Date: Sat, 23 Mar 1996 16:31:20 -0600
  6. Organization: customer of Internet America
  7. Message-ID: <31547BB8.31D7@iadfw.net>
  8. References: <4gum82$14v4@info4.rus.uni-stuttgart.de> <MPLANET.31530e9djcoffin98993e@news.rmii.com> <31536199.219868914@nntp.ix.netcom.com> <315418FA.1508@iadfw.net> <1996Mar23.202452.14793@sq.com>
  9. NNTP-Posting-Host: dal20-22.ppp.iadfw.net
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.01 (Win16; I)
  14.  
  15. Mark Brader wrote:
  16. > 
  17. > lfw@iadfw.net writes:
  18. > > Mike Rubenstein wrote:
  19. > >  > You've missed a rather subtle point.  Such extensions are legal but
  20. > >  > they do not introduce integer types.  The standard defines the signed
  21. > >  > integer types as being signed char, short int, int, and long int (and
  22. > >  > similarly for unsigned integer types).
  23. > 
  24. > > It must be pretty subtle!
  25. > 
  26. > Not at all.
  27. > 
  28. > > Can you cite specific Clause references ...
  29. > 
  30. > It's in 6.1.2.5/3.1.2.5:
  31. > 
  32. > # There are four "signed integer types", designated as signed char,
  33. > # short int, int, and long int ...
  34. > 
  35. > It says four, not four or more.
  36. > 
  37. > # For each of the signed integer types, there is a corresponding
  38. > # (but different) "unsigned integer type".
  39. > 
  40. > It is true that size_t is specified by 6.3.3.4/3.3.3.4 as having an
  41. > "unsigned integral type" rather than "unsigned integer type", but the
  42. > draft Record of Reponse 2 confirms that these terms were not intended
  43. > to be distinguished.
  44. > 
  45. > Thus if x is of type size_t, printf ("%ul\n", (unsigned long) x); is
  46. > safe under the present standard.
  47. > --
  48.  
  49.  
  50. Let me try one more time to understand what makes an extension "legal"
  51. and what makes an extension "impossible".   
  52.  
  53.  Am I correct to understand that it is impossible for an implementation
  54. to define an extension that introduces new integer types?  (I'm pretty sure
  55. answer if "yes" for the above stated reasons).
  56.  
  57.  Am I correct to understand that is is possible for an implementation to
  58. define an extension that introduces a new type named  verylong  that
  59. behaves very much like, yet is not, an integer type?   If so, what clause
  60. of the Standard makes that extension possible?
  61.  
  62. (Let's get that much understood before I go off and study this some).
  63.